1. Field of the Invention
The present invention relates generally to a field of communication, and more particularly, to conference messaging between telephony devices in a first network and devices in a second network.
2. Description of the Related Art
UPnP is a set of computer network protocols promulgated by the UPnP Forum. The goals of UPnP forum are to allow devices to connect seamlessly and to simplify implementation of networks in home data sharing, communications, and entertainment and corporate environments. UPnP achieves this by defining and publishing UPnP device control protocols built upon open, Internet-based communication standards.
The UPnP architecture allows peer-to-peer networking of Personal Computers (PCs), networked appliances, and wireless devices. It is a distributed, open architecture, based on established standards (e.g., TCP/IP, UDP, HTTP and XML). The UPnP architecture supports zero-configuration networking. An UPnP compatible device from any vendor can dynamically join a network, obtain an IP address, transmit its name, convey its capabilities upon request, and discover presence and capabilities of other devices.
Similarly, UPnP devices can leave the network automatically without providing any unwanted state information. UPnP protocol provides discovery, control and eventing mechanisms. Discovery is enabled using Simple Service Delivery (SSD) protocol. All the control messages are in the format of Extended Markup Language (XML). Eventing follows the General Event Notification Architecture (GENA) protocol. Using these technologies, UPnP makes availability and unavailability of the UPnP devices on the fly to the other devices in the network.
The UPnP forum also provides telephony services for extending user experience in a home to access telephony services like messaging services, presence services or Call handling (PS/CS call). For example, the UPnP telephony service allows the user to access messaging services like sending a message using an UPnP device which does not have the messaging capability.
As analogous to UPnP Device Architecture (DA), telephony defines three kinds of devices, namely a Telephony Server (TS) that provides messaging, and presence related services to the user, a Telephony Control Point (TCP) to initiate actions provided by the TS and a Telephony Client device (TC) for media related handling and providing input and output of the UPnP device.
Current UPnP telephony messaging service allows the user to send different types of messages (SMS/MMS/Chat IM/Email). The messaging service supports page mode messaging (e.g., SMS, MMS, email, and the like) and session mode messaging (e.g., chatting). The messaging service also allows the user to group a number of messages into a single messaging session whereby the message service defines actions to create the session and group the messages into a single messaging session. The UPnP telephony messaging service also allows a user to modify the existing session.
However, the user of the UPnP device cannot use the messaging service for conference messaging with WAN devices, and joining/rejoining the conference messaging session due to different TCP/TC devices in the UPnP telephony based home network that may not support all media content types. For example, a television set can display plain text but may not support pictures. Further, if pictures need to be retrieved, then content negotiation has to be carried out before a conference messaging session is set up. Also, the WAN devices are unaware of the media capabilities of the TCP/TC device.
If media capabilities, such as supported Multipurpose Internet Mail Extensions (MIME) types, are not taken into account, then it is possible that the UPnP telephony device or the TCP may receive unsupported media content from the WAN devices, not at all supported by the TCP, in the conference messaging session, resulting in inconsistent user experience with respect to the conference messaging session. Currently the UPnP telephony messaging service fails to capture and provide dynamic session information (e.g., user leaving or joining the session) associated with the conference messaging session as dynamic information is required to push to the user rather than pull from the TCP.